1. Field of the Invention
The present invention relates generally to the field of creation of software for computing systems in which the fundamental underlying construction principles for constructing software have existed essentially unchanged since their first creation 60 years ago or so. The present invention is a new and radically different construction method for constructing human-computer data-activity systems (colloquially and together generally called “software”) that bears almost no resemblance to any previous software construction system. The invention is the result of some eleven years of research, trial and error and practical tests into discovering the anatomy of the human data system and its data handling methods which lead to the discovery of a new type of machine termed an Any-to-Any machine, of which only a handful exist in the world, all of which are extremely powerful machines—some examples are binary code, the transistor, base 10 arithmetic, music notation system, display screens, genetic code human data handling and human activity handling. Methods were then invented (which are the subject of this patent) to construct data and code in a computer environment so as to make them comply with the newly-discovered Any-to-Any machine construction principles. People using software constructed with this new construction system perceive the software as being intuitive and very easy to use, doubtless because the new style of software produced by the new construction system handles data in a similar manner to the way a human handles data with other humans. The new software construction system is also more powerful in that it has enabled software to be constructed comparatively easily and quickly that does things state of the art software is not able to do—such as enabling unskilled and untrained users to construct their own applications without programming and enabling test samples from the 85% of the world's population who are not computer users to use the resulting applications without any outside assistance whatsoever and to like it sufficiently well that 47% of non users tested wanted to buy it and a further 26% thought they might buy it, for a total of 73%. The average for all users was 73% would buy it, 12% might buy it, total 85%. The invention also enables computers to meet one definition of intelligence and enables them to learn from humans and from other similar computers, and does both simply and easily.
2. Description of the Prior Art
Eighty five percent of the world's population does not use computers even today. Acceptance and use of computer systems could be significantly increased by making computer systems easier to use which essentially means making them behave the way a human expects a data handling entity, whether human or computer, to behave. Equally, software should be capable of more powerful applications than are seen today—capabilities such as full language control of a computer, or a computer running a company by itself may sound like science fiction, but there seems to be no real reason why that should not be possible. However the particular software/data construction system in use in the state of the art has two critical groups of shortcomings that between them block the way forward. Firstly, (despite perhaps superficial appearance to the contrary) there are many indications that the state of the art construction methodology is a self-limiting construction system that is now closely approaching or has reached its intrinsic limits and never will be capable of really satisfying a human's data needs, and secondly, the construction system imposes a system for handling human data that is so radically different from the data handling system in normal use between people, that, if practiced by another human, that person would be certified insane on many counts and criminally insane on others. Since insane people are hardly “easy to use” it is not surprising that computers handling data insanely are not easy to use either (at least not for the 85% of the world's population that do not use them). Hence there is an urgent need for an alternative software/data construction system which is not self-limiting and which uses a computer data handling system that humans would consider to be sane, normal, usual, and hence “easy” if a human did things in a similar manner. The system of the invention has been tested and proven to construct software that has radically improved acceptance and ease of use in public tests, is not self-limiting and is more powerful than can be constructed with current methods.
Software Construction Today
Firstly, to briefly describe the nature of today's state of the art software construction and consequent operation, virtually every type of conventional software is constructed as one or more large masses of executable code that is written in one or more source code files, which are compiled into one or more executable files, which typically produce interrelated output data of various types. A particular data output is intimately related to the particular code that produced it and that data cannot be used (without an intermediate transformation step performed by other code) by other executable code built to produce other data. The format of the output data, and the screen displays rendered by the software for showing the output data, are integrally controlled and set up by the executable code, which may further involve integral cooperation with facilities provided by the operating system and other applications, such as commonly-accessed objects, DLLs, device drivers, and the like, all of which result in a staggering number of enormously complex executable files that are almost beyond human comprehension in their complexity. The method consists in essence of building an integrated “lump” of software which is compiled into one or more extremely large blocks of unimaginable complexity—the Windows operating system, if printed in books, is said to go from one end of a football field to the other. These blocks of software operate on other blocks consisting of data of a type that that software has been constructed to produce and handle when interacting with a human. The format of the output data, and the screen displays rendered by the software for showing the output data, are integrally connected to and dependant upon one another and set up by the executable code. Once compiled, the executable files can run on an appropriately equipped computer system to implement the pre-configured functionality and render the output screens that are almost entirely pre-configured.
Apart from the indisputable prosperity brought directly to some 15% of the world's population by their use of this state of the art software, state of the art software constructed by current software system construction methods has other significant observable overall results that are far from positive. Some of these are:
Firstly, the computing system resulting from today's software methods is one in which, of the world's population of over 6.7 billion, about 5.7 billion (85%) (by latest estimate) do not use computers and yet these are the very ones that most need the assistance a computer ought to be able to provide to them, while the comparatively prosperous remainder (about 1 billion or 15%) benefit from the current system, while struggling to deal with it and control it—and using only a small portion of the available functionality by most reports.
Secondly, observation of the software market over the past decade shows that the enthusiasm and adoption that used to greet the latest version of general purpose office suite software (which is an indicator of general computer use to do useful work) has evaporated, and today, the arrival of the latest office version passes unnoticed and adoption is poor. Despite billions of dollars of effort put into adding important new functionality to office suites and operating systems, the result (compared to the leaps forward that used to occur) can be best characterized as re-packaging with little addition of user-significant functionality and less and less enthusiasm for upgrading being evident. The following press quote is typical “AnchorDesk Nov. 27, 2007: 6 upgrades that are downgrades. Here are a few choice examples of upgrades that are downgrades, and why you're better off with the older tech: Vista, the obvious number one product for this list. Vista is the new shiny operating system Microsoft released to replace Windows XP. Except it hasn't, because it's a poor upgrade. It's slower, bigger, and buggier. Many people, not just those in the opportunistic Apple ads (and Apple has its own problems), would rather get a new computer with the old XP operating system.” E-week.com, Steven J. Vaughan-Nichols, 28 Jan. 2008: “Technically, Vista is pure misery. It eats system resources like an elephant does peanuts, Windows applications break and its so-called improved security is a joke. I know it. You know it . . . . Vista is not being picked up by corporate users. It's one thing to drop copies of Vista Home Basic and Premium on Best Buy customers who don't know any better. It's another thing entirely to get CIOs and IT managers to spend—or should I say waste?—billions on Vista.” Recent general use software offerings can be characterized as different icing on the cake, and as more ways of eating cake, and different recipes for cake, but can no longer be characterized (as they previously could be) as a more and greatly improved cake—and this is not due to lack of resources trying to produce more cake.
Similarly, the arrival of the latest and greatest CPU used to be highly anticipated, but today the introduction of the latest and greatest chip passes almost unnoticed—CPUs long ago became good enough for current general purpose software, and this has itself lead to a steady erosion of chip maker's margins because the added functionality the new chips offer is not enough to command (as it used to command) premium prices except in niche markets. In effect, the unwritten pact that hardware provides the power and software uses that power usefully has been steadily breaking down more and more over recent years, as software is less and less able to add further functionality for which there is a demand. The end result is hardware and software industries that both appear to be stymied, and in need of a solution to open the door to significant progress.
This phenomenon of increasing efforts producing diminishing returns—and eventually almost no returns at all (despite massive and unimaginable resources and effort)—is characteristic of self-limiting building or construction systems that are reaching their intrinsic limits, and examples of such self-limiting construction systems in other spheres are easily found. For example, building systems for buildings remained essentially unchanged for thousands of years and up to the early 1900's the highest buildings were cathedrals, where the top stories were unusable for any practical purposes. Buildings could not be built higher with existing materials or they fell over. Increasing effort in terms of time and expense of building ever-stronger supporting structures lead to diminishing returns—the effort could not add any significant number of usable floors. In short, the particular construction system in use was self-limiting. However, that building system was also self limiting in another way. Structures built with the system were not strong enough to support personnel lifts even though such lifts did exist at the time—coal mines hundreds of feet deep were only usable because of the lifts that serviced them—hence the lifts existed, but an above-ground building structure strong enough to support lifts tens of stories high generally did not. Due to the absence of ease of use lifts, few dwellings or offices existed higher than 5 stories even though builders could easily build higher—nobody wanted to drag shopping and the baby up forty flights of stairs, let alone pay extra for the view. Hence, the building construction system was also self-limiting by lack of ease of use. At the beginning of the 1900's a new building system arrived—steel and pre-stressed concrete—and from that point on the face of construction changed. Previous limits dissolved overnight, structures could be built tens of stories higher, and were strong enough to support lifts, allowing the higher floors to command a significant premium that was more than enough to pay the additional cost of construction of the higher floors—the self-limiting ease of use limit was also removed by the new construction system. Both of the self-limiting facets of the previous construction system resulted from a single root cause—lack of the adequate structural strength in the old construction system.
A human-computer data-activity system is a system in which a programmer attempts to make a computer do things that the human considers to be useful. The computer manipulates (changes) one commodity only—human data—and human data is to the computer, what structural strength is to the building system. For the computer, human data is the single founding factor and therefore, the methods and the way in which it is used by the computer and by the human, are totally critical. To be easy for the human, the data handling method used by the computer and that used by the human should be identical or at least very similar and if they are, there will not be much for the human to learn before he can use such a computer, as it will do what he expects it to do under nearly all circumstances. He has prior experience—since birth—with the human data system; if the computer's data system is radically different to the human's data system (as it is today) the computer will be “hard” to use. Everything it does will have to be newly learned before it can be used, because the human has no prior experience with the computer's different data handling system that is practiced by all state of the art software. It is not a question of which one is right and which one wrong. It is a question of whether they are the same or whether they are different, or not, and since the computer has to please the human, and the human is not there to please the computer, the humans' data handling system—whatever that may be—should be adopted by the computer. The computer should not, as it does today, force the human to adopt and learn the computer's data handling system.
One hundred percent of the world's population of humans have their various habits, ways, methods and systems of manipulating data between one another even if nobody has previously identified what those methods and systems are. Hence the human does have a system and ideally, so that the computer and the human handle data in the same fashion, which would be easiest for the human, it is necessary to identify what that human data handling system is and then implement a computerized version of it in a computer.
Humans, without doubt, exchange data between one another and the data exchanged produces useful activity, much as when a boss orders a secretary to “email to Joe the fax about applies that I sent to Pete last week” and the ability of humans to do this sort of thing makes one human easy to for another human to “use”. Humans and computers also exchange data with the intention of producing useful results and clearly, while one data-action system (the human one) is easy (for humans) to use, the other one (the human-computer data-action system) clearly is not, and moreover, since it cannot even execute simple commands such as the one illustrated above, something is clearly badly wrong in the state of the art human-computer data system. The apparent inability (despite unimaginable resources never before seen on earth) to add significant functionality (to build higher) and the evident lack of ease of use (inability to add lifts) again despite the availability of unimaginable resources and multiple university faculties working to advance existing technology, bear uncanny indications of similarly to the self limiting phenomena and characteristics of yesterday's self-limiting building construction system and point to the lack of the right construction system—or the use of the wrong one in the state of the art—as being a possible root cause of the problem. The construction system concerned in the building example was the system and methods used to build buildings. In the case of computers, the construction system that could be the root cause of the mentioned problems would be the software construction system and methods (the system used to construct the human-computer data-action system in a computer)—the human-computer data-action system being the system by which data is received, from the human, recorded, handled and then related to action by the computer so as to cause useful activities that are all, in some manner or another, transformations and manipulations of data.
Examination of the State of the Art Construction System—Basic Description of One to Many Machine System Type
Similarly to the previous building construction system that also endured a long time after its first use, until now there has been one, (and only one) basic method and system of constructing software (the human-computer data and activity system) and that construction system has remained virtually unchanged in its basic principles and methods over the last sixty years—from the very first beginnings of software. There have of course been many developments of the basic method—such as object oriented construction and so on—but the most basic principles have remained unchanged, with tightly integrated code (using many mechanisms such as inheritance and hierarchical construction in the name of code efficiency) on the one hand, producing separate data of a particular type on the other. The code is in one or more files or blocks of one type and the data produced by it is in one or more files or blocks of a completely different type and structure, and the code block acts on a block (file) of data.
This construction system is a member of one of the two basic types of machine system that have now been identified in the world today as a result of the investigation of the human data system that lead to this invention. The existing software constructions system and methodology fully complies with the requirements of one of those types of machine—the One-To-Many machine type. (The world “machine” is used here in the sense defined by Merriam Webster of “an assemblage of parts that transmit forces, motion, and energy one to another in a predetermined manner”—and clearly these parts can be either physical or logical and are logical parts in this case). A One-To-Many machine is defined as:                “A machine in which One of something works with Many of something else, in a manner that is intrinsically hierarchical and is intrinsically limited.”        
Examples of such One-to-Many machines are the CD machine system, where there is one CD player, and many CDs read and played by it, or one word processor, and many word processing documents processed by it, or one spreadsheet software One-to-Many machine, and many spreadsheets processed by it, or One operating system, Many programs run by it—and so on, with each One-to-Many machine being a separate entity. The vast majority of machines and machine types that are encountered in daily life are One-to-Many machines constructed with One-to-Many machine construction methods and principles, and state of the art computers and software and today's human-computer software data system are no exception to this—they too are One-to-Many machines built with One-to-Many machine construction methods.
The One-to-Many construction methods used in state of the art software construction and their interrelated data handling are extremely well documented in thousands of books and known to some degree to nearly all computer users and do not require repetition here. If any individual part of such a software construction is examined it will be seen to fit the One-to-Many machine definition given above. In effect, “software” today is a large number of individual One-to-Many machines that are interacting with one another to make an overall, big One-to-Many machine—much as a car is a large number of smaller One-to-Many machines working together to make a big One-to-Many machine that is a car—one car, many roads driven by it.
One-to-Many machines are typically constructed by assembling several components that are sometimes single function and often multi-function. But the nature of the components from which the machine is built is such that one component needs to be assembled with one or more other and specific components in order to function—it cannot function when related to any other component in the machine, but only when related to certain specific other components in the machine. For example, a memory chip in a CD player cannot function if attached to the spindle of the motor turning the CD and will actually prevent the spindle from turning so that, if miss-assembled, it may even break the machine. The memory chip can function—but only when attached to another specific component—a circuit board. In order to function and not break the machine, the memory chip has to be assembled with a specific fixed and hierarchical relationship with power supply components the chip needs to operate and other components to send and receive its data.
The defining characteristics of a One-to-Many machine are as follows:
Defining CharacteristicOne-to-Many MachinesFunctions performed by each ComponentOften more than one(building block) from which the system is madeOther Components in the machine with which aA Component can only operate withspecific Component can be related and functionspecific other Components withwhich it was designed to operate.Relationship of any one specific Component toFixedanotherComponents exist in a HierarchyAlways - hierarchy is intrinsicHierarchy of Component assembliesMandatory - intrinsicFlexibilityNone outside of built-in One-to-Manyrelationship. Almost totally limitedMachine purposePerformance of specific and alwayspre-defined functions
A first important characteristic of One-to-Many machines is that they are very good at what they do and completely useless at doing anything they were not designed to do. For example, a lawn mower is very good at moving lawns, but is wholly useless for baking bread. The oven is great for baking bread but can't mow lawns. A word processor is great at changing words around on the screen but can't create a presentation; a spreadsheet is wonderful for calculating numbers but can't email them and so on. The second important characteristic is that data from a one One-to-Many machine, can't be used by another One-to-Many machine without transformation. One CD player designed to play Many CDs, cannot play a tape without first transforming the data onto CD. The One-to-Many Tape player designed to play Many tapes, can't play a CD without transforming the data first. Effectively, transferring data from one machine to another requires a translator and the multi-million dollar database integration industry is essentially a translator production industry that arises because databases are also One-to-Many machines none of which can use the other's data without translation. Getting them to talk to one another needs translation and plug together mechanisms that are the more exotic equivalent of taking music on a tape and putting it on a CD. As a solution to providing individual translators to translate between any two One-to-Many software constructions, current effort is to provide them all with translators from their own language into a common language—XML. While that is effective in enabling data to be transmitted, it does not solve the further underlying problem, which is that the data structure of One-to-Many database A, is different to that of One-to-Many database B, and hence even when they can transmit data using XML as a common language, unlike a human who can receive more or less any data and do something useful with it, the two One-to-Many databases cannot necessarily do anything useful with the data that has been received through the common language or relate it to their own data. Data received from the one can't fit in the other as their data structures are different and hence, XML or no, the multi-billion database plug-together industry is still needed to work out how to transform data from Database A in Database A structure, into data that can be used or related to the data of One-to-Many Database B with its warp and woof Database B One-to-Many data structure—one database, many tables. Many records in Table B, all related to one record in Table A.
Self Limiting Increase in Complexity
When applied to building software, the One-to-Many machine construction methods and principles of the state of the art result in a data-activity system that is inherently self-limiting in a number of striking ways, the first of which is that adding functionality results in ever-increasing complexity to the point that the complexity becomes overwhelming and prevents further progress, a phenomenon that arises in the following manner:
One to Many construction systems are intrinsically hierarchical and the One-to-Many software construction method that is the state of the art software construction method, is indeed self-limiting in that adding an arithmetic increase in functionality causes a logarithmic increase in code complexity. That phenomenon is easily observed throughout the software world and can for example be seen when comparing the abilities of the first word processors, which would fit on an 8″ 128 Kb disk, and those of today, where the program is X thousand times the size, but does not have anything like X thousand times the functionality—code bloat as it is commonly termed. Yet, if one were to imagine everything one might be able to do with text—particularly in terms of its look where possibilities are almost limitless, and compare that with what a word processor today can do with text, an extremely large gap is still apparent, far larger than the gap between the first word processors and those of today. Since recent iterations of major word processors show little addition of user-useful functionality of any importance to the general user, despite the application of gigantic resources, clearly, something is preventing forward movement and the only available candidate is the construction system for the data/software machine that is proving troublesome and resistant.
Today's software, when analyzed and broken down, consists of many small One-to-Many machines, connected together and all related to and affecting one another and assembled into one very large One-to-Many machine system. As a result, if a new functionality has to be added, it affects things in very many individual small One to Many Machines throughout the code, and not always in very predictable ways, leading to a) adding one additional functionality requires many new code connections—causing “code bloat” in conventional parlance b) considerable expense arising from the considerable difficulty of adding functionality. The errors and unpredictable results arising form the complexity are such that today's leading operating system, with all the billions behind it, requires weekly patches (repairs) in order to function at all and even then, shows many flaws, most of which occur unpredictably. This complexity of the code connections between the many One-to-Many machines working together is the fundamental cause of the self-limiting nature of the One-to-many construction system because adding more functionality requires logarithmically greater effort to do so, and this effort eventually, somewhere, becomes so great, and the commercial return for the effort so minimal, that at the end of the day it can't be done in practical or profitable terms, and hence the system is self limiting in terms of effort required to add functionality. While there is no defined limit, the effect is that of a wall of glass—it is always possible to see where the software needs to go and do, but getting there is like trying to go through a flexible glass wall that imposes ever-increasing resistance to progress, a resistance that eventually becomes overwhelming or not commercially viable to overcome.
In contrast, with a human, the opposite is the case; an arithmetic increase in ability (a single new ability just learned) results in a logarithmic increase of functionality as he can apply the new ability anywhere at all and use if with every other ability he has. So if a human learns to add up numbers, the human can do this anywhere—on a sheet of paper, in an email, a letter, in a presentation, on a drawing, on a wall or on the back of an envelope and do it with a pen, a keyboard, or with sand and his finger. The human can take almost Any ability and apply it to Any data (whether doing so is useful or not), and that kind of ability is typical of an Any-to-Any machine which will be described in more detail later, but which is rudimentarily defined as a machine in which Any component (for example the ability to add numbers) can be used with Any component (for example a sheet of paper or with sand).
The dramatic difference and contrast between an Any-to-Any machine and a One-to-Many machine in terms of increase of complexity for a given increase of functionality is easily understood by considering the example of an old fashioned telephone switchboard. Such switchboards had many holes, each one representing a different telephone extension or number and the holes could be connected together by a telephonist with a wire with a jack on each end by placing one jack in each hole (representing an extension or number) to be connected. This was an Any-to-Any machine in that “Any component (hole) can be used with (connected to) Any component (hole) (by a wire with two jacks) in a manner that is not intrinsically hierarchical (there is no hierarchy between the two holes being connected together) and is intrinsically unlimited (it does not matter if there are nine holes or a thousand as long as the wire is long enough).
Supposing now, that if there are four holes, there are then 6 combinations—ways they can be connected directly to one another. If one more hole is added, there are now 10 combinations, so adding one hole, adds four combinations. If a further hole is added making 6 holes, there are now 15 combinations, so adding one hole, this time added not four, but five new combinations showing that combinations (functionality) increases disproportionately to holes (complexity). So as this little Any-to-Any machine grows, arithmetic increase in complexity produces logarithmic increase in functionality—the same phenomenon that is observable in a human where, when one new ability is learned the humans has thousands of ways he can apply it.
Now supposing that instead of being constructed as an Any-to-Any machine, the switchboard had been constructed as a One-to-Many machine, by wiring each hole directly to every other hole with its own wire—that would make it into a One-to-Many machine—one hole, many wires. In effect, what happens is that whereas only one wire was required before, no matter how many holes there were, now 4 holes require 6 wires to connect them all directly, 5 holes require 10 wires and 6 holes require 15 wires—the addition of 1 hole added 4 wires but the addition of 2 holes added 9 more wires—not only were more wires were need than holes, but adding holes increased the wires disproportionately, and an arithmetic increase in functionality has produced a logarithmic increase in complexity. The enormous increase in code size and complexity with little increase in software functionality seen over the last years is additional characteristic of and a confirmation of the One-to-Many nature of state of the art software.
Imagine now that each hole is one of the atomic meanings of a word (so that a single hole is not just the whole word “fax”, but that each hole represents just one single meaning of a word—such as the one meaning of fax, the activity of faxing (as opposed to another meaning of the world “fax” as being fax the piece of paper that can be looked at, or still another meaning of the one word “fax” being the word for the machine with which to send faxes). Now in the state of the art, the programmer uses current One-to-Many construction methods to connect each meaning directly to each of the other meanings he wants enable the user to be able to use, and does this using code. For example, when he builds a One-to-many address book (one address book, many addresses record by it) he connects “First Name” to “Fax” (number) using code. Because this is a laborious process he uses various One-to-Many tricks to cut down the connections, so he writes a One-to-Many field structure which he connects by code to a One-to-Many screen display structure which is connected by code to a number of One-to-Many DLLS which are connected by code to . . . etc. He certainly does not even try to connect every meaning to every other meaning of everything as the human can and does from time to time, so he does not wire together with code the First name in the address book to First name in the accounting program because he can't wire everything direct to everything else or he would be there for ever.
On the other hand, the human that he is attempting to satisfy, can, at any time and at the slightest whim, decide to connect any of these holes (data points or events) directly together in a new way that has not been done before, for example by giving the instruction: “if my wife calls, FAX this to Joe”, in other words ordering the computer to connect together one point of 1) the his wife 2) calling, and others of 3) the activity of faxing 4) “this”*(document) and 5) Joe. He is asking the computer to connect certain things together in a way that the programmer has not code-wired them together yet. If enough demand occurs for a specific connection, then that new functionality gets added—which needs nine—or nine thousand—more wires to connect it. Because so much complicated code wiring is needed to connect new data points together, the programmer does not wire the least essential ones and the result today is that there is one Joe Brown in the address book and another in the accounts program. While they are actually the same Joe Brown, the programmer has not wired them together, and so the computer has no way of knowing that they are the same Joe Brown. Consequently if one has just created an invoice addressed to Joe Brown in the accounting program, you can't give an order such as “email it to Joe” because Joe's email address is in the email program where the accounts program can't get at it, and even if it could, the computer does not know they are the same Joe Brown anyway.
Describing problems of directly connecting an additional hole in the switchboard is a comparison of microscopic size compared to the real problems that exist in trying to satisfy the human. Flying over a city at night and considering that each of the lights is a data point that the human may at any time demand to connect to any other light (data) that can be seen anywhere, and then imagining how much wire (code) would result by attempting to wire each lamp directly to each other lamp, soon leads to the conclusion that there would be a pile of wire over the city many miles high; yet this is what today's One-to-Many construction systems attempt to do. As this analogy shows, the objective of connecting Any data to Andy data as the human does and as he would preferably require a computer to do too, is an un-unachievable objective with the state of the art One-to-Many construction system, in which every hole has to be pre-wired to every other hole, and is a system that will self limit at some undefined point with a business decision that adding another 9,000, or 90,000 code wires is not worth the commercial return of doing so.
In effect there is an urgent need for an alternative construction system, in which the programmer does not wire anything to anything at all, but instead builds code wires with plugs on the end and hands these wires with plugs on the end to the user and lets the user get on with plugging together whatever data and activities he wants to plug together. Such a system would reverse the present logarithmic increase of complexity produced by an arithmetic increase in functionality, and instead produce a logarithmic increase of functionality for an arithmetic increase in complexity.
Hence, there is a first requirement for a human-computer data-activity construction system in which adding additional functionality does not add complexity disproportionately but preferably reverses the situation so that—as with a human—arithmetic addition of complexity results in logarithmic increase of functionality.
Self-Limiting Ease of Use
In addition to being self-limiting from the construction aspect, today's human computer-human data-activity (software) construction system and methodology is also self-limiting (just as the previous generation building construction system was) from lack of ease of use.
Where a human is concerned, the more things a human knows how to do—which in computer terms, would be more the more software it has—the easier that human would be to use (work with)—a man is “easier to use” than a baby which cannot even understand what it is asked to do. If a human knew how to do a lot of things (equivalent to a computer with a lot of software), he would be very “easy to use” as he could do pretty well anything and everything he was asked to do. But with a computer today, the exact opposite is the case—the more software it has, and the more the software can do, the harder it becomes to use. They say that even experts take years to learn to use drawing programs—programs that mostly do less then most humans can do with a few pencils, rules and paper.
If one were to take a few ordinary texts and then construct a written menu containing each and every action a human could do to that text and its display (just as today there is a menu entry for each action a computer can do) it is predictable that one would land up with a menu the size of a volume of the Encyclopedia Britannica because what a human can do to data is extensive. The truth of this is easily demonstrated by looking at a text and thinking of all the things one could tell one's secretary or another person to do with the data. A human would easily invent very many things to do (that actually software today cannot do) such as:                “take that paragraph, turn it sideways, put a box with curve lines around it and then put that in the upper part of this photograph of an apple.”        “Check if any other machine in the office has a document with that paragraph in it and bring me the document concerned.”        “See if that paragraph was ever sent by someone to Joe Brown in Seattle.”        
And so on. Such a menu would be so large as to be impossible to use in anything like a workable manner
In fact, where there are thousands, or tens of thousands of possible things—or even more—that the other entity (person or computer) could be asked to do, a language based command system is the only practical solution. Humans, in order to use one another, use a language interface and that enables them to control almost limitless abilities in one another. Language control is very easy indeed for humans to use—they are trained in it and use it many hours a day each day every day since soon after birth.
So when the number of activity possibilities becomes very large, a menu control system is no longer workable and instead a language selection mechanism is needed where the user can tell the computer—at least in writing—what the person wants it to do, just as that person would tell another human—a secretary or an employee—what they wanted done.
Considering that even today's software exceeds people's ability to easily understand and use its menu systems as the example of drawing software shows, the ability to control computers with normal language would be a desirable improvement, even today.
But there is a reverse side to using language as a control system—if the number of possible activities is not reasonably comprehensive compared to what a human could do with the same data, a language control system is wholly unworkable and this problem arises as follows. On the one hand, humans are very good at limiting their orders to what they think the other person ought to be able to do. A mother will not order her 10 year old son to do the household accounts, but she will tell him to sweep the yard. The other side of that, is a person will tell another to do anything they think the other should be able to do. The household accountant will get asked how much was spent on food, and will get asked to email that to the spouse.
While a person has a fairly good idea of what a child or a household accountant ought to be able to do, the only yardstick he has for what a computer ought to be able to do with given data, is what he knows he could do with it himself or what he knows he could ask another person to do with it. But, if one then compares what a computer can do with any specific data and what a human can do with the same data, it is shocking to observe how very little the computer can do out of everything the human can do. Because of this lack of functionality, even if a language control system were to be installed to control a computer today, it would turn out to be useless and would not be used. It would be useless because it would give the user the freedom to order anything he can think of, and the human would then order anything he thinks the computer ought to be able to do. But since that is an awful lot more than the computer actually can do, when he gives normal language orders, he would find that 95% of his commands could not be done and would fail. After some experience of that, there would inevitably be a frustrated and irritated request to, “tell me what you can do then?” And the only possible response to such a request is a menu—a menu being simply the presentation of ordered lists of what the software can do. Hence, the language command interface, even if available, would be of little use and would not be used because too often it would fail to produce any result because the list of what the computer can do with the data is tiny compared to what a human could do with the same data.
Therefore in order to give a computer a language control system, a first prerequisite is to enable that computer software to do pretty well anything the human might expect the computer to be able to do with the data concerned. But therein lays a catch because today, as already discussed, the existing list of functionality that a computer can do, is quite tiny compared to what a human can do with the same data—and more functionality can't be added because of the self-limiting nature of the construction system being used.
So before language control becomes usable (even if available) the computer has to be made to be able to do pretty well anything the human might expect it to do and therefore might order it to do. But this is impossible today, because creating even the inadequate existing number of activities has already resulted in such complexity that adding any number of further useful activities with the existing state of the art One-to-Many machine construction is almost impossible—as recent efforts with many programs such as Office Suites and Vista have shown.
But it is the nature of things that one wrong solution causes other problems and in fact, today's menu system is not very workable either and is a problem in itself—a problem that derives eventually from the One-to-Many construction system which renders language control impractical because adequate functionality to make language control practical cannot be constructed.
The problem with menu control systems is simple to understand. While menus are often compared to a “tree” with “fruit” (icons) at the end of the branches, they are a tree that the user monkey has to climb blindfolded—he cannot see at the outset at the end of which branch his desired fruit lies, he cannot know if the fruit he wants even exists at all or and cannot know what it looks like. He can only see the fruit that are available once he gets to the end of a particular branch—only to find that none of the available fruit are the fruit he wants and he must start again, and blunder round the tree again. As the available fruit (menu actions) increase from the tens to the hundreds to the thousands, the use of the menu becomes an increasingly daunting task—much like climbing the stairs to the tenth or to the fortieth floor each time and eventually, this effort becomes just too much trouble for the ordinary user. As a consequence in the state of the art, the user is found generally not to use more than 7-10% of the available functionality. Since this cannot be due to lack of desire to use the functionality—a boss will give a secretary or employee much more complex orders to do than are available in existing software—this lack of use of functionality can only be due to absence of desired functionality or difficulty of accessing it or both. In effect the menu system itself is self-limiting the use of the provided functionality. In effect, while it is not possible build higher than the tenth floor with the existing construction system, the tenth floor has been built but few people want to use the tenth floor even if it is built—nobody wants to drag the shopping up that far or blunder blindfolded round the menu tree for another hour or two trying to find out how to do something, that maybe the software cannot do in the first place.
Hence, there is a requirement for a human-computer data-activity construction system that does not limit the ability to add functionality, so that adequate functionality can be added to make easier, human-like language control of the computer acceptable and useful, and so make the power of computing available to more of the world's population because practically everyone in the world can use language control without having to learn anything.
In summary of one set of problems arising from the nature of the software/data construction system, the state of the art One-to-Many data-activity system construction system is a self-limiting blind ally and Catch 22, in which more functionality is needed—but cannot be provided due to increasing complexity resulting in ever-increasing effort in return for ever-decreasing improvement, and even if the needed functionality is provided, it cannot be accessed and used by the user due to excessive menu complexity, and cannot be accessed by language either, due to insufficient available functionality to make language control practical. The result is a series of interlocking “gotchas!” that block forward progress all of which arise from the nature of the state of the art, One-to-Many, 60-year old, self-limiting software construction system and methods still in use today. The effect is that of a dead end, just like the previous generation building construction system was a dead end, and on the very similar counts, a) inability to build higher (build more functionality) and b) lack of ease of use.
While this shows a further need for a non-self-limiting construction system or method to enable software functionality to progress, there is yet another, interlocking set of problems that also block the way forward in the state of the art, and which, if not solved at the same time will also prevent material progress, as follows:
Data Insanities in State of the Art Software
To describe now, the data handling imposed by the state of the art construction system, it is not only the self-limiting nature of the One-to-Many human-computer data-activity system that is in urgent need of improvement by making available a construction system that is not self limiting, but the data-activity system enforced by the state of the art construction methods also requires major improvement. The current computer data system or data model, however one wishes to refer to it, is so different to that in use by humans with other humans, that if humans behaved the same way in their data handling with other humans, they would immediately, and with little hesitation, be certified as insane. Such a certifiably insane data system can hardly be regarded as an ideal data system for a computer that the human has to deal with daily. A computer using a data system that would not be certified as insane if used by another human would be better.
While there are very many ways in which state of the art computer data handling phenomena would be classed as certifiably insane if done by a human, of these, the following eleven data insanities cover a wide range of state of the art software data handling problems and (from a human viewpoint) would be obvious and major insanities if done by a fellow human. Each one is directly caused by the One-to-Many construction system forcing data constructions and behavior that are in direct conflict with the “sane” data handling as practiced by humans:
Data Insanity 1—One to Many Data Exchange
A first example of this data-activity system (software) insanity in the state of the art occurs because a major characteristic of the One-to-Many machine type is that it is almost totally and extremely limited—all such machines are very good at what they were built to do, but are completely limited and completely inflexible and are more or less incapable of doing anything they were not specifically built to do. One of the many limits of the One-to-Many machine that is quite characteristic of this machine type is that data created by or for any one particular One-to-Many machine cannot be read or used by a different One-to-Many machine type without prior transformation or translation. For example, a One-to-Many system CD meant for a CD player cannot be read or played by a tape recorder—the data must be transformed first and placed on a tape. A One-to-Many spreadsheet cannot read data created by a One-to-Many word processor without transforming the data first through OLE or some other mechanism such as XML. Relational databases—the primary human data repository and recovery mechanism that are today responsible to hold, relate and provide most human electronic data—are a particularly dramatic example of a One-to-Many system and the limitation resulting from such systems. In a database:                One set of field names in one table is programmatically related to many entries in that table        One entry in Table A is programmatically related to many entries in Table B        One Table is programmatically related to many views of it        
And so on. “Programmatically related” as far as the human user is concerned, means that these things are more or less welded together never to be undone or changed—at least, not by him—and can't be changed on the fly by anybody, even if they are a programmer. This extreme inflexibility and rigidity derives directly from the hierarchical nature of the One-to-Many machine construction, where, for example, the One-to-Many methodology is reflected throughout the warp and woof of the relational database construction. The strict, inflexible, hierarchical nature of the stored data to the One-to-Many relational database machine type that produced it results in such inflexibility that, whereas humans can talk to one another (proved they use the same transmission media (language), different databases can't talk to one another even when they do use the same language to communicate to one another (e.g. XML) and a multi billion dollar industry exists to try to glue together again the world population of database Humpty Dumptys that perhaps should never have been created as un-human-like separate data lumps (databases or applications) in the first place.
This One-to-Many hierarchical methodology produces databases that can't exchange data usefully (unlike humans who can exchange any data with anybody) stems from the days when computers were tiny and getting them to do anything at all was a miracle. In those days storage was equally tiny as well as horrendously expensive. Because of those physical constraints, difficult and equally miraculous software mechanisms that promoted compactness and “efficiency” were at a premium. While—at first glance at the time—such mechanisms were apparently efficient, there was no or little thought detectable in the literature of the epoch as to what the human data-action system might be and how these “efficient” mechanisms might relate to it. One of these universally adopted efficiencies was the hierarchical construction system throughout software, in which the properties of one piece of code were inherited from or depended on, the properties of another piece of code—or usually of many pieces of code—thereby (apparently) saving the many repetitions of the code that would normally be required to (re)produce the property. This hierarchical structure construction method of software, of this depending on that, extends throughout the structure and permeates state of the art ordinary software and data storage software, where One entry in table A is welded together (with code) to many entries in table B.
Hence, and because of the hierarchical nature of the One-to-Many software construction system, each piece of software has its own data format just as each database type does (and in the case of databases made with the same software, they each have their own structure as well), and therein lies the root cause for thousands of human-computer data systems that cannot communicate their data between one another without billion dollar enterprises to assist in the transfer of data and why, even today, the largest multi-billion dollar corporations are unable to see in their own computer system A, data that is produced in another continent in their own computer systems B, C, D, E, F. The best they can do is to browse the data provided that each database has a web interface.
If a situation were to exist in the human data-action system, whereby two groups of humans speaking a common language (much as many different data bases “speak” XML), could not usefully exchange information, one of the two would be considered certifiably insane, and on this count, the computer data-action system, by human standards, is certifiably insane by reason of the inability of one entity to exchange data usefully with another without an armada of technicians to help.
Hence, there is a requirement for a human-computer data-activity construction system such that any computer can exchange and usefully use, any data with any other computer system i.e. where each computer able accept and relate other computer's data, just as a human can accept and relate other human's data.
Data Insanity 2—Joe Brown
A second major area of data-activity system (software) insanity (by human standards) is easily illustrated with something as simple (and as fundamental) as an address book, which is a One-to-Many construction like all software today. In an address book, One address book (complex package of code) is rigidly associated and welded together with code by a programmer to Many addresses which are further welded together by code to the storage format of the data and still further welded together by code to the output screen intended to display the data. Superficially, this appears reasonable and normal, but because this address book and the associated systems such as a spreadsheet are all One to Many machines (different One-to-Many machines), the result is that the exact single and one entry of the name Joe Brown used in the address book cannot be used elsewhere by other software, for example in a spreadsheet called “Joe Brown account”, and, as far as the computer is concerned, as soon as that spreadsheet is saved, the data “Joe Brown” appears in the computer twice, or, when “Joe Brown” is further entered in the body of the spreadsheet, three times, or when entered in the body of a letter, 4 times, and so on. It is not possible to re-use the exact one “Joe Brown” entry in the address book again (for example) in the accounts software, because this one Joe Brown entry is not accessible by itself and without anything else, but can only be accessed by using the whole address book itself (a multi-megabyte construction) at the same time. Since it becomes impossibly complex with One-to-Many address book construction to transform the data for other One-to-Many machines (such as a word processor or spreadsheet) and then relate it back to the individual address book entry, this is simply not done—and in fact more or less can't be done as the resulting complexity is overwhelming—a further example of the self-limiting (and user-limiting in this case) effects of the state of the art One-to-Many construction method.
Whereas, in a person's head, there is only one Joe Brown, in a computer, due to the self-limiting nature of the One-to-Many construction method, coupled with the hierarchical structure imposed by it, there may be one “Joe Brown” in the address book, several hundred “Joe Browns” in documents, some more “Joe Browns” in accounts software, and there is no way at all of telling whether these are all the same Joe Brown or different ones and if so, which is which. If a human did not know whether the Joe Brown he wrote to yesterday, is the one to whom he owes $100, or the one who has a Seattle address and is married to his sister, he would be thought to be insane and it well might be said that today's software and data construction system that results in thousands of “Joe Browns” where a person has one only, and in a computer being complete unable to determine which Joe Brown is which, is indeed an insane construction system, in that it produces a data system, which, if seen in another human, would be considered quite certifiably insane.
This illustration points out several facts in the state of the art human-computer data-activity system—firstly that the human-human data-activity system is not the same as the human-computer data-activity system. Secondly it illustrates the fact that a computer will be considered to be easy to use, to the degree that it does what the human would expect another human to do under the same circumstances, based on the human's experience of interaction with other humans. The human has one “Joe Brown” and so does the friend he talks to, and dealing with that friend is intuitive and “easy”—he knows what to expect. But whereas the humans have one “Joe Brown” the computer has thousand, all of which are the same—maybe—and that is not at all what the human expects and as this demonstrates, this state of the art One to Many construction method results in non-intuitive data systems that, by human standards, are insane. The fact that computer data handling, if seen in a human, would classify that human as certifiably insane serves to illustrate how very different are the underlying data-action systems or models.
The illustration of the address book built by state of the art One-to-Many construction methods also illustrates other certifiably-insane characteristics of the data-action system resulting from state of the art methods. If one were to transform just an address book into physical elements like wood and wire, so as to see its construction more clearly, the resulting model would be a system in which a particular component, such as a wire (an address), is only packaged and sold and delivered to consumers preassembled with a headlamp (the address book)—the consumer can only use his one “Joe Brown” entry by using the address book at the same time. So in order for the consumer to connect his TV to the TV antenna on the roof, the consumer would buy the wire (with its cannot-be-disconnected-by-the-consumer headlamp), and connect the TV to the antenna on the roof. And then he would have a headlamp dangling off his TV antenna on the roof and nobody would be surprised if all his neighbors would ask one another what certifiable lunatic lived in that house and whether he should be locked up before he did something really dangerous. Yet this is the situation throughout the software world, where a particular component, such as a wire (First Name), is only packaged and sold and delivered to consumers preassembled with a headlamp (Address book). Again, a human confronted with this situation would consider it insane, and would consider the manager of a hardware store selling wire only with headlamps attached to it to be a candidate for the lunatic asylum. The state of the art software situation is no less insane simply because it is not a physical construction that is so obviously ludicrous as to cause the neighbors to laugh in pity.
Hence, there is a requirement for a human-computer data-activity construction system in which only a single instance of any given data exists and all re-uses of it are only references to the original data, so that when there are multiple Joe Browns or their equivalent, it is always known which one is which, just as a human would know which one is which.
Data Insanity 3—Backwards
A third area of One-to-Many data-action software construction method that results in the human-computer data-action system differing enough from the human-human data-action system so as to be classed as insane if it were to occur in another human, as follows:
Today's state of the art software-data systems work completely backwards when compared to the human data-action system. In the human system, data is received as Step 1 “email to Joe the fax about applies that I sent to Pete last week” and then action is produced as Step 2—the secretary, having received the data, then goes off and performs the actions required. Step 1 is data reception and recording and Step 2 is actions done with that (now recorded) data and in consequence of its nature. The secretary finds the fax (one action) and then performs a second action (emails it to Joe). In short, data (received order) drives the choice of activity (software). Today's software does it backwards. The software must be chosen by some higher outside authority—the computer can't do that itself—and activated as Step 1, (find software) and then—as Step 2, the data (the fax about apples) can be found. Having been found, a new Step 1 is required that the human does not need at all, and new and different software must again be activated by a higher outside authority and then as a new Step 2, the email can be sent—once the outside authority has performed the additional action of transferring the found data to the email program (as software does not necessarily exist to do that for him).
This problem arises because the data-activity systems constructed by the One-to-Many state of the art construction method, result in each software having its own separate data that is the only data it can handle and that only it can access and that in turn has the effect of constructing multiple logical paired boxes in the computer each consisting of a lump of software and another lump of data created by that software that is in a format only that software can read. As soon as there is more than one software that could need to be used next, something or someone has to decide which software is to be used next. Because there is no such something or someone in a computer in the state of the art that can do the deciding, the human has to decide. Hence the state of the art software construction method imposes a sequence that cannot be violated, in which the software must first be accessed or opened, in order to do anything at all with the data, so that the software in use chooses which data and data types can be dealt with. If an email program is being used, it cannot access and manipulate accounts data in a database. The system produced by the state of the art One-to-Many construction system is a software driven system—the software in use dictates the data to be handled.
However, the human's data/activity system is the exact reverse—it is a data driven system in which the data in use decides the activity (i.e. the software) that shall be used with that data. The human accesses or retrieves the data (“finds” it in computer terms) and then does something to the data in consequence of what the data turns out to be, as in this example. “What other friends do we have? Ah, of course, Joe! (retrieved data) We should invite Joe to our party too. Shall we phone him, send him an email or send him a letter? He has no phone and no email? OK, let's post a written invitation (action) to him then”. The data in use, selects the action to be performed on it, which simply is not possible in a One-to-Many system in which the One (software) has to be activated before it can do anything to the Many—its data type.
In summary, in today's human-computer data-activity system or model, Software drives Data—which is the exact reverse of the human-human data system where Data drives Software.
Were a human to claim that, before he could think of a person's name, someone had to tell him to activate his people thinking abilities he would be considered insane. If a person could not remember who Joe—or who anybody at all was—unless someone first said to him the people-thinking (address book software) activation phrase, “think about people OK?”, then his trip to the lunatic asylum would be swift.
Hence, there is a requirement for a human-computer data-activity construction system in which data drives software selection, so that commands given by the user to the computer to perform specific activities can be performed in the manner the human expects them to be performed and not backwards.
Data Insanity 4—Data Boxes
A fourth aspect of the One-to-Many state of the art software construction model producing a human-computer data-activity system that would be classified as insane if seen in a human, is as follows. In the case of a human, their knowledge (data) and abilities (software) are an integrated whole—there are no separate functional divisions inside a person's head for letters, another for accounts, and yet another for addresses and a third for leg movement activities and another for hand movements and another for address remembering activities and yet another for calculating activities, and so on. A human does not think “ah, I will think about leg movements, let's see what we have got here, Ah yes, left leg—forward!” He accesses each activity and each atom of data directly. He does not have to through any command or structural hierarchy to do an action. He does not have any vias—things he has to go through, or boxes he has to get into before he can do something.
But the One-to-Many software and data construction methods in the state of the art result in large lumps or clusters of distinct bodies of knowledge software and associated separate lumps of activities—software; the word processor code over there, the documents produced by it; the spreadsheet code over here, and documents produced by it in that box there. As a result it is not possible to get to anything at all directly—one can only get there via some hierarchical thing else.
If a human were to claim that he had in his head, a similar division of data and activities, to those that a computer has in its head (hard disc), that person' journey to the lunatic asylum would be swift. If a human had in his head, the filing “system” that a computer has in its head, he would be considered insane indeed, and yet he can find more data faster than a computer can (by itself), so his filing system, whatever it is, can't be so bad. The computer can perhaps remember it much better, but the human can find and access (what he can remember) much better.
Hence, there is a requirement for a human-computer data-activity construction system in which data and activities are a homogenous whole and in effect, as with a human, any data (not just the data from a specific program) can be related to or associated with or interact with any other data in the computer so that each and any individual activity known to the computer can be applied to any of the data in the computer to which that activity is applicable, just as a human can do.
Data Insanity 5—Cannot Branch
A fifth aspect of the One-to-Many state of the art software construction producing a human-computer data-activity (software) system that would be classified as insane if seen in a human, is as follows. A human, in his behavior, will branch off from one thing to another and back to the original thing with total fluid ease. He will for example, start writing a letter, by hand, let us suppose, branch to the phone that he picks up to check the address with someone, branch to his address book, enter the address into the phone book and go back to his letter where he suspended execution in the middle, put in the address and continue writing.
Now take the same example in a One-to-Many email program, in which everything is solidly wired by the programmer to not quite everything else. The user starts to write an email, and opens the address book's address list display to choose an email address for the email, and finds it is not there. He attempts to open the address book to add the missing address only to find he cannot, because he is not allowed to do anything else “while a dialogue box is open”. He has to close the address chooser list (terminate the execution), go to the address book, open it, add the contact, re-open the address chooser list and continue—the program cannot branch its execution and then return. It can certainly do all kinds of branching internally, but is prevented from doing so for the user by its One-to-Many this-wired-to-that construction, where one cannot get rid of the headlamp (suspend the chooser list execution) in order to use some wire (add an address). Many examples of inability to suspend execution occur in daily use of state of the art software, but it is only by directly comparing hard-to-use computer behavior to easy-to-user human behavior that they become easily visible.
This is important because, for a computer to be able to execute language orders that a human will give such as “send the email to Joe about apples at his weekend address”, it has to be able to suspend execution much as a human would and after starting the email, be able to branch execution, lookup the weekend address, get it from somewhere if it does not have such an address, and return and carry on. A human who gave such an order, only to come back some time later to see a message staring at him “cannot do action while a dialogue box is open” is not going to be happy.
If one were to give an order to a secretary to “send an email to Joe about apples at this weekend address” and the boss were to return an hour later only to see her starting at her address list and to be told “sorry, I can't progress this until you tell me to close my address choosing list so I can add a new address to the address book,” she would be thought to be insane. Her trip to the exit door would be a fast one.
Hence, there is a requirement for a human-computer data-activity construction system in which execution can be suspended at any time and then resumed when desired.
Data Insanity 6—Separately Controllable
A sixth aspect of the One-to-Many state of the art software construction producing a human-computer data-activity (software) system that would be classified as insane if seen in a human, is as follows. As pointed out previously, in order to use language control of a computer, it is necessary that the software is able to do anything and everything that the user reasonably expects, as otherwise, language control will fail. This requirement is most easily described in relation to things visible on the screen, where it is hence a requirement that each visible aspect of whatever is the on the screen, needs to be able to be separately controllable by the user's orders and controllable in such a fashion that the user's order (data) controls the execution he wants (software) and not the other way round as previously described and as occurs in the state of the art. This means that if the user wants the left edge of all boxes that appear on the screen to be blue, thick and composed of four lines instead of just one, the middle ones of which are to be wiggly, then                The color of each edge must be individually accessible and separately controllable        The thickness of each edge must be separately accessible and controllable        Lines must be able to be added in without limit.        Each of the lines on each edge must each one of them be separately accessible and controllable for thickness and for color and for form        
In the state of the art One-to-Many machine construction it is simply not possible to control each thing separately—for example, to control one edge of a box. It is even less possible to do so across multiple programs, both because the internal construction of each program is composed of many (somewhat different) One-to-Many machines, so that part of a box cannot be controlled separately. And the One-to-Many machines are anyway not quite the same in all the different programs and causing a change across many of them at once is a complication which, due to the nature of the code, would quite by itself cause considerable code bloat.
The argument is sometimes advanced by programmers that it is “not sensible” to make everything customizable, and users “don't want” everything to be customizable. But in a test system that could be so customized, after a few days, no two systems looked at all like one another, just as no two people are identically dressed, nor do they have houses identically decorated and furnished. A human such as secretary can apply any ability she has to any data, without regard to whether it is “sensible” to do so or not. She can—and children often do—color a photograph blue for example, and it is not up to the programmer to dictate and decide in a god-like manner what the human is or is not allowed to do, it is up to the computer to do whatever the human wants done. If one were to tell a secretary to draw boxes on a sheet of paper and make the left edge all boxes blue, thick and composed of four lines instead of just one, the middle ones of which are to be wiggly, and she could not do that, she might not be considered insane, but she would at least be considered to be retarded. But in order to do this, each and every visible thing must be individually and directly accessible without having to go through anything else.
Hence, there is a requirement for a human-computer data-activity construction system in which each of the activities of which the computer is capable are entirely separate from one another so that each one can be separately controllable, and in such a manner that the ability can be applied and the action done, to whatever is in the computer to which it should be physically possible to do that action.
Data Insanity 7—can't Act on its Own
A seventh aspect of the One-to-Many state of the art software construction producing a human-computer data-activity system (software) that would be classified as insane if seen in a human, is as follows. If one person gives an order to another, then the first person expects the other to go away, get on with it and come back when done. In effect then, a computer should be able to be given orders, and get on with them without bothering the giver of the order, and report back when done. In the state of the art this simply isn't possible. It is not possible to chain orders together as can be done with a person (first do this then do that). If this is attempted on the rare occasions when it can somewhat be done, for example by selecting a number of word processing documents and then ordering them to be printed, what actually happens is that the word processing software opens, and each document flashes on the screen, obliterating whatever work is in progress, prints, and the next document to be printed flashes up on the screen covering whatever one is working on. This occurs because, due to the On-to-Many machine assembly method, the data is welded (by code) to the program (much like the wire and the headlamp are attached to one another), and the part of the program that transforms words (making them bold etc) is welded to the screen display part of the program and the part of the program that prints, is welded to the screen display also. Hence several documents can not be printed without displaying them on the screen, and in effect, the headlamp dangles off the TV antenna. If a secretary were to be given an order to photocopy or print several documents, and as she copied each one, she rushed over to the bosses desk, slapped the document down covering whatever he was working on and then a half second later snatched it away and then came back a few seconds later and did the same thing again with the next document, she would be regarded as out of her mind.
Hence, and again, there is a requirement for a human-computer data-activity construction system in which each of the new activities can be added without affecting old ones, so that each activity can be used without affecting any other activity at all.
Data Insanity 8—Word Based
Data Insanity 8: an eighth aspect of the One-to-Many state of the art software construction producing a human-computer data-activity system that would be classified as insane if seen in a human, is as follows. It can be envisaged that ultimately, the computer that would be easiest to use would be one in which language can be used to command the computer, so that commands such as “send a fax to Joe” and “find me the fax from Joe” can be correctly executed, something that has not been possible on any broadly useful scale with software constructed with One-to-Many software construction methods in use today.
The word “fax” has several meanings, as do most words and what needs to be done, depends on which meaning is in use. For example, “send a fax to Joe” requires a send activity to SEND the fax, whereas the command “find me the fax from Joe” requires a completely different activity to be done—that of FINDING a fax. To respond to language commands in a useful manner, a computer would have to be able to detect which meaning is in use and act accordingly. In the above example, the first command has the meaning of fax, the activity, while the second has the meaning of fax, the piece of paper.
In the first command, document preparation software is required to prepare the fax itself and another separate One-to-Many machine (fax software) is also required to send the prepared fax. In the second command, neither of those pieces of software are required, and instead another completely different software (find software) is needed (which again shows that the data has to drive the choice of software as described previously). In order to be able to process such commands correctly, the software has to be built to deal with the different atomic meanings individually of words and not just words themselves. Additionally each of those atomic meanings (that the computer has to be able to handle separately, and differentiate between one and another) has to be able to drive and select the correct software to perform the required action.
The above commands illustrate the fact that, to make language command and control of a computer possible, there are two pre-requisites. Firstly, software has to be constructed so that it acts not on the basis of words, but on the basis of atomic meanings. It has to be a meaning machine and not a word machine. But all state of the art text handling and command control software are word machines, not meaning machines. Secondly, those atomic meanings have to be able to be associated on the fly (since there is no prediction when the human will use a particular meaning) with equally atomic software that will perform the activity the meaning requires. In other words, at its lowest level the software data system has to be constructed from atomic meanings and atomic activities (software actions) to go with them, such that meanings and actions can be associated as required, on the fly, and are not each preassembled in large lumps as is the case in the state of the art.
In fact words themselves are each little One-to-Many machines—one word, several meanings and many of them are actually quite complex little assemblies of several One-to-Many meanings. For example the word “dog” is a One-to-Many machine (one word “dog” and Many (several) meanings of it) and even something as apparently simple as “s” that can be used with “dog” to make “dogs” is another One-to-Many machine in its own right that is not written as a separate word, but (meaning-wise) does act as if it were a separate word: one word “s” and many meanings of it. For example “s” can mean, a) more than one b) next thing belongs to previous thing c) is. Hence the word “dogs” is an assembly of two One-to-Many machines. Some words are an assembly of 25 or 30 different pieces and far more than that is not uncommon. For a computer to handle these words correctly, the pieces have to be disassembled first and the computer has to find out or be told in some manner, which meaning is in play and act accordingly, just as the human figures out which meaning is in play and acts accordingly, in all instances.
In contrast to this, the state of the art One-to-Many machine software construction is built round multi meaning words and not on the basis of atomic (single) meanings. Even worse, it acts on mis-defined multi-meaning words with strange counter-intuitive and unknown-to-most-humans assortment of meanings assigned to them that are found nowhere else. Thus click the world “file” and one sees that in current software the word “file” can be defined to mean “new” or “open” or “print” or “archive” etc—“file” is one word, representing all of those meanings, none of which are in use elsewhere the world as different meanings of “file”. Additionally, the One-to-Many machine construction does not permit, and actively prevents, associating atomic meanings with activities—apart from anything else mechanisms simply do not exist to do so.
Now if a boss were to say “file that” to his secretary, and she were to respond “how do you want it printed?” (which is what the Page Set-up command on the File menu amounts to), she would be regarded as insane. If the boss were to say to her “edit this” and she were to respond “what do you want we to find?” (Find is on the edit menu) she would again be regarded as insane.
Hence, and again, there is a requirement for a human-computer data-activity construction system in which the system functions based on (correct) and atomic—single meanings—just as its human does.
Data Insanity 9—Limits
A ninth aspect of the One-to-Many state of the art software construction producing a human-computer data-activity system that would be classified as insane if seen in a human, is as follows. Today's state of the art One-to-Many machine construction forces limits on its users that would be considered totally insane if practiced by another human. For example, a state of the art address book is typically limited to two or four addresses. But what if a person—Joe brown—has five or seven addresses as some do? Such address books are limited often to one mobile phone—but what if the person has several as many do? The only solution is to create another record—in effect create a yet another Joe Brown in the computer so that the computer thinks there are two Joe Browns when there is only one. And once that happens, how can a computer execute a command such as “call Joe Brown on his mobile”? Which Joe Brown? One has to create a second address record because the underlying address database is rigidly wired on a One-to-Many basis to a display, and all the parts of the display are code—welded together, so no way exists to expand the screen on the fly and add another 1 or 100 address or 1 or 100 mobile numbers. If a human, being told by her boss that the third mobile number for Joe Brown was xyz, absolutely insisted that the new number was not a number for the Joe Brown they both knew, and insisted on writing a new address record for another Joe Brown and then asked ingenuously what the address of the new Joe Brown is, she would be considered extremely insane.
Hence, and again, there is a requirement for a human-computer data-activity construction system in which the system does not limit the user in any way he does not limit himself.
Data Insanity 10—Execution Memory
A tenth aspect of the One-to-Many state of the art software construction producing a human-computer data-activity system that would be classified as insane if seen in a human, is as follows. Today's One-to-Many software usually does not record either user orders or their results, nor does it record what orders were executed when. However, one of the very basic and universal human specification methods is to identify something by specifying the execution that was previously performed on that thing. These are examples, “get me the thing I printed yesterday morning just before the printer stopped working”, “find me the spreadsheet I faxed to Joe yesterday”.
If a secretary was given such orders and responded “what thing? I do not remember printing anything” or “What printer stopped working? I don't remember any printer stopping working” or “what spreadsheet was that? I don't remember faxing a spreadsheet to Joe”—she would be judged insane.
Hence, and again, there is a requirement for a human-computer data-activity construction system in which the system records orders and their outcome and relates them to the item on which that execution was ordered.
Data Insanity 11—Security
An eleventh aspect of the One-to-Many state of the art software construction producing a human-computer data-activity system that would be classified as insane if seen in a human, is as follows.
The lack of security in today's software is well known and the following quotes illustrate that the problem is still current: 1) CNet AnchorDesk newsletter Nov. 13, 2007: “A Microsoft executive calls the ease with which two British e-crime specialists managed to hack into a Windows XP computer as both “enlightening and frightening.” 2) “CNet AnchorDesk newsletter Nov. 14, 2007: “Over the past two years, data leaks have compromised more than 150 million personal data records.”” 3) ZD Net, Nov. 28, 2007: “On Wednesday, the SANS Institute released its top 20 security risks for 2007. It's pretty bleak across the board. There are client vulnerabilities in browsers, Office software (especially the Microsoft variety), email clients and media players. On the server side, Web applications are a joke, Windows Services are a big target, Unix and Mac operating systems have holes, backup software is an issue as are databases and management servers. Even anti-virus software is a target. Meanwhile, instant messaging, peer-to-peer programs and your VOIP system are vulnerable.” Billions of dollars of resources are put into making operating systems secure by one industry, while other industries have sprung up around its failures to do so—such as a second entire industry of anti-virus software and a third industry of firewalls and a fourth industry of security and anti data theft, all of which have grown up around the security defects that are inherent in software constructed with the current One-to-Many construction system. These very expensive industries are mostly occupied in trying to shut the door in future after at least one—and usually many—horses have already bolted. But the Swiss cheese nature of the One-to-Many constructions produced by the state of the art One-to-Many construction system is such that there is always another hole that enthusiastic horse thieves can find and exploit and despite the combined efforts of four well funded industries and doubtless many research centers, the daily press continues to report almost weekly more and often extremely expensive horses bolting, some of which incapacitate millions of users and cause untold loss and irreparable damage. Clearly, and as everyone agrees, there is a major need for improvement in the security of state of the art software.
The security problem arises due to the inherent nature of the One-to-Many constructions of state of the art software, built with state of the art One-to-Many constructions systems, in the following manner. 1) as already described, the One-to-Many construction system inevitably forces different software and different data formats for each different type of data the user wants to deal with. 2) It also forces this construction to turn out as one large multi-megabyte lump of software on one side, dealing with one large lump of data on the other side and this of course, is also true of a browser which is one of the most frequently security-breached One-to-Many constructions. The same is also true of the operating system (one large lump of software over here, many other pieces of software and data that use it). 3) Because a large lump of mega-multi-function software on the one side has to do many different things to large lumps of any of the correct type of data that comes its way, there are hundreds or thousands of points of interchange between the lump of data and the lump of software handling the data. 4) Software, right up to the very moment a command is given that causes the operating system to execute it, is just data to the operating system like any other, and the operating system has to, one way or the other, deal with and do things to all the data in the system. But because software is just data—right up to the point it is executed—the only way to prevent damage from malicious software that is just data until executed is to: a) remove all connections by which data connects to software, but ultimately, this is impossible because today's software has to bite off a lump of data, masticate it and then spit it out again transformed, or b) detect which incoming data is malicious and which is not. And that is an activity of closing barn doors on the rear ends of departed horses 5) Further, since the number of things the software can do, due to its self-limiting construction, are so few compared to the requirements of the human which are so many, it is necessary to enable others to create functionality and help bridge the gap between the lump of software and data, and these bridges have to be marketed in the form of Application Programming Interfaces and Browser controlling software like visual basic and such-like. These openings provide still more avenues for incoming data (that is actually malicious software when activated) to exploit. 6) Because open hooks into the complex of software have to be maintained by the Ono-to-Many construction of today's software in order for the software to connect with the data and do anything at all, and because there are so many thousands upon thousands of little functions that need to get done, preventing malicious software masquerading as data from executing always will continue to be an operation of closing the barn door after the horse has bolted. In essence the nature of the construction makes it impossible to tell what is software and what is not, and impossible to identify which software belongs to the computer already and which software just walked in through the door and hence the software receptionist (which does not exist in the state of the art) ought to find out if the boss—the user—wants (the non-existent software receptionist) to get it execute or not.
Now translating these strange phenomena into human terms, if the local drug peddling criminal walked into the office of a company or a multinational, and handed the receptionist a letter and ordered her (spam re-mailing software) to send it at once to every address in the company's central address book, and she did so; or if he handed the receptionist a flame thrower (malicious software) and told the secretary to at once burn the building down, or burn all the company's records, and she did so; or if the same criminal walked in the door, handed her a gun (a computer virus) and told her to go and shoot all the security staff, and she did so, she would be arrested within minutes, and immediately classified as not just insane but as criminally insane, and indeed, there is no visible reason why today's software construction system should not therefore also be certified as criminally insane, except that, until now, there have been no saner alternatives.
Hence, and again, there is a requirement for a human-computer data-activity construction system in which the system does not allow data (that is actually malicious software) into the system in the first place.
What is Needed
In summary of what is needed, there is a requirement for a human-computer data-activity construction system that is not subject to at least the following self-limiting aspects and does handles data sanely, so that:
A. The construction system is not self-limiting
    1) Adding additional functionality does not add disproportionate complexity.    2) The ability to add functionality is not limited either by construction restraints, or by usability.B. The construction system does not force Data Insanities (by human standards) into existence, with the result that (amongst many other desirable things):    1) Any computer can exchange and usefully use, any data with any other computer system,    2) Only a single instance of any given data exists and all re-uses of it are only references to the original data    3) Data drives software selection    4) Activities as well as data form a homogenous whole and any data can be related to or associated with or interact with any other data in the computer in a manner that is not intrinsically hierarchical and is not intrinsically limited.    5) Execution can be suspended at any time and then resumed when desired.    6) Each of the activities of which the computer is capable are entirely separate from one another so that each one can be directly accessed and is separately controllable,    7) Each of the activities of which the computer is capable are entirely separate from one another so that new activities can be added without affecting old ones    8) The computing system functions based on atomic—single—meanings as the human does.    9) The computer does not limit the human in any manner that he does not limit himself.    10) Orders and their outcome are recorded and related to the item on which the execution was ordered.    11) The system does not allow data (that is actually malicious software) into the system in the first place.
The single objective of software and data construction is to enable the computer to do what the human wants done and in some manner to do it under human control or direction. The human's demands of a computer derive fundamentally from and service his data interaction needs with other humans—it is his data interaction activities with other humans that produce what he defines as success, and a computer is expected to help with that. (The word “data” is used throughout in its broadest sense to cover all information emitted by or transmitted between humans). This essentially means that the programmer, in providing more functionality, is always attempting to enable the human-computer data-activity system to do what a human-human data-activity system can do already, but do it on demand, by a computer, and hence, more quickly, cheaply and comprehensively.
Hence there is a fundamental need to provide an interacting data and code system—a software system—in a computer that functions (at the level with which the human interfaces with the computer) in a manner that is sufficiently similar to the way the human himself functions when dealing with data and activities and when dealing with other humans, that the human finds dealing with the computer to be instinctive and easy because the computer does it the way he is used to doing it since birth.
Equally, because the human-computer data-action system, even at a superficial glance is insane by human standards, understanding the state of the human art in the human's own human-human data-action system that the programmer is attempting to satisfy is a vital first step and pre-requisite in order to be able to see what the differences are between the human's data methods and the computer's data methods if any. Once these are identified they will show and point the way to improvements that need to be made to the human-computer data-activity system to make it work more similarly to the human-human data-activity system so as to produce computers that are more powerful and easier to use, and easy enough to use so that the other 85% of mankind who do not use computers today could use computers in the future.
In the simplest terms, the need is firstly to discover the systems and methodologies used by humans to deal with data and activity with one another—the human data-activity system. Only after that has been discovered and adequately described is it then possible to do what is needed and invent methods to construct computer emulations of the human data-activity system in a computer. Or, to put it more colloquially, a prior understanding of the human data-activity system is needed, in order to invent methods to construct software that behaves in manner that a human would describe as intuitive. If that it well and correctly done, it should be able to handle data pretty well the same way as another human can, and hence, should be as easy to use and as powerful as the human's own data system, with the added advantage that the computer can store unlimited data verbatim and compute it very rapidly.
Part of this is that the computer should be able to correctly process orders that are given to it normal language—orders such as: “if my wife calls from Los Angeles at 10.01 Thursday January 2009 send her the email about bananas” and this is not possible in the state of the art. Equally, if the computing infrastructure is to be controllable by language the computer has to be able to correctly execute language orders such as “if my wife calls from Los Angeles at 10.01 Thursday January 2009 send her the email about bananas that I sent to George when he was in London and I was New York”.
For a computer to be able to execute language orders such as “if my wife calls from Los Angeles at 10.01 Thursday January 2009 send her the email about bananas that I sent to George when he was in London and I was New York”, it has to be able to identify who “my wife” is and which email is “the email about bananas that I sent to George when he was in London and I was in New York”. The subject of identifying such things is the subject of how a human unambiguously specifies things such as emails to another human, and, in contrast, how software specifies things such as emails.
In the state of the art, software unambiguously identifies things in terms of file path plus file name, or by the size in bytes, or by the time of saving or modification, all of which must be meticulously accurate in order for the identification to be successful. While a human is capable of unambiguously specifying millions or billions of things to another human, from something he saw in a newspaper ten years ago, to the fact that he wants a glass of water now, he is totally incapable of doing so using software's data specification system. He cannot, for example, remember the exact size in bytes, or the exact path and file name, or the exact time (to the second) of saving or sending the letter that he wrote yesterday, let alone of specifying those things for each of the other documents or files to be found in today's average computer. In the absence of the ability to specify data upon which an activity is to be performed in terms that enables software to unambiguously locate the target data, language orders such as “if my wife calls from Los Angeles at 10.01 Thursday January 2009 send her the email about bananas that I sent to George when he was in London and I was New York” will routinely fail when given to the computer and comprehensive language control of a computer is also impossible in the state of the art by reason of that problem too, as well as by reason of the other problems described—all of which have to be solved in the same software construction in order to make language control possible.